Tool-call gate (toolgate) and gateway scope enforcement - #59

…ructured request log

Three defects surfaced while putting the gateway in front of the
tool-call gate, each fixed with a regression test in
hack/tests/gateway_http_test.go:

1. httpapi.NewRouter built an empty in-memory API-key table, so the
   identity-service validation path (HTTPAPIKeyValidator) existed but
   was never used and every X-API-Key request got 401. The router now
   validates against IDENTITY_URL; API_KEY_VALIDATOR=memory keeps the
   empty table for tests.
2. Scopes were validated, cached and placed in the request context, and
   nothing checked them against a route. middleware.RequireScope now
   enforces a route scope map after Auth: DefaultRouteScopes (reads need
   "read", writes need the resource's scope) merged with ROUTE_SCOPES_FILE
   ({"METHOD /prefix": "scope"}); "*" covers everything; an unmapped route
   requires "*" (fail closed). Refusals are 403 insufficient_scope with
   required_scope named. Keys created with the default ["*"] are
   unaffected.
3. The gateway expected {"valid": true, ...} from
   /internal/v1/apikeys/validate and the identity service never sent a
   "valid" field, so even a wired validator would have refused every key.
   Identity now says valid: true; the gateway accepts a 200 with a tenant
   whether or not the field is present and refuses valid: false.

Also: the request log line could never carry request_id or tenant_id
because Logging ran outside the middleware that set them; a per-request
holder (RequestInfo) fixes that, and the line is now a JSON record
through slog with scope_required and scope_decision. TOOLS_URL mounts
/v1/tools/ for a provider's tool endpoint, and the proxy forwards the
validated scopes as X-Scopes so a downstream gate can check per tool.

…thorization

Six ways through the gate, each with a regression test. The first four were
verified against testdata/policy.json before the fix: all returned allow.

1. A ceiling compares numbers, and toFloat only handles numeric kinds, so a
   quoted amount made the rule not fire: send_payment with {"amount":"999999"}
   passed the 5000 ceiling as a clean scope-only allow. A value that cannot be
   compared is now a deny.
2. Rule.evaluate returned "not fired" when the constrained argument was absent,
   so any tool whose upstream accepts a synonym, an alternate casing or its own
   default walked past ceiling, allowlist, suffix, prefix and sensitive_field:
   send_email with {"recipient": ...} was allowed where {"to": ...} is denied.
   The guard now fails closed, as evaluateLookup already did for the same case.
3. Call.Scopes replaced the policy's granted_scopes outright, and the value
   comes from the X-Scopes header, which the gated agent controls. Sending
   "*" switched the tool_scopes layer off: delete_invoice, whose scope the
   policy does not grant, was allowed. Scopes now intersect, so a caller can
   narrow the grant and never widen it.
4. DefaultRouteScopes had no /v1/tools/ entry, so tool calls fell through to
   the "*" default; the gateway then forwarded X-Scopes: "*", which is the one
   value that neutralised the gate's own check. With (3) the layers no longer
   cancel, and POST /v1/tools now maps to tools:invoke.
5. POST /v1/holds/{hash} was unauthenticated and took the approver's name from
   the request body, so an agent replayed the hold hash it was handed in the
   202 and approved its own bank-account change, with the fabricated name
   recorded as human approval. GET /v1/records was also unauthenticated and
   served Args verbatim: payment amounts and recipient accounts to anyone who
   could reach the pod. Both now need OPERATOR_TOKEN, and are refused rather
   than open when none is set. Argument values are off the records response
   unless EXPOSE_ARGS=true.
6. Route prefixes matched with HasPrefix and no segment boundary, so a sibling
   silently inherited a shorter route's scope: /v1/tools/list_invoices covered
   /v1/tools/list_invoices_and_delete, and /v1/work would cover a later
   /v1/workflows. Under-protection, not a 403, so nothing surfaced it.

Also, on the audit record the component exists to produce:

- Arguments were round-tripped through float64, so an account number past 2^53
  reached the tool as a different number and the artifact recorded the changed
  one. Decoding uses UseNumber; toFloat already handled json.Number.
- publish errors were discarded, so a tool ran while its event was dropped and
  only the in-memory chain survived. Failures are logged and counted, and
  /v1/records/verify reports the count.
- The chain is process-local, so a restart starts again at genesis and
  VerifyChain still answers ok: a fresh chain and a truncated one looked the
  same. Each gate now has a chain_id, reported by verify, so the discontinuity
  is visible. Persisting the chain is still open.
- The image baked internal/toolgate/testdata/policy.json in as the default
  POLICY_FILE, so a deployment that forgot its ConfigMap authorized real calls
  against the fixture, which grants payments:send. No policy is baked in and
  the gate refuses to start without one.

docs/TOOLGATE.md states the trust boundary the code now enforces: identity
headers are attribution, the operator endpoints are not part of that model.
docs/AUTHENTICATION.md notes that HTTPAPIKeyValidator caches a validation for
five minutes with no invalidation, so a revoked key keeps working until it
expires.

Tests: 8 in internal/toolgate, 4 in aex-toolgate/internal/httpapi, 2 in
aex-gateway/internal/middleware, 3 cases in the gateway's scope table.

CVE-2026-56854 (CRITICAL, golang.org/x/crypto/ssh) is fixed repo-wide on main
by #60. aex-toolgate and hack/toolgate-harness are new here, so they do not
exist on that branch and pinned v0.52.0 of their own.

Same reasoning as #60: the path is not reachable (AEX opens no SSH connection;
x/crypto arrives under the nats and mongo drivers) and govulncheck passes. The
bump keeps these two modules level with the rest of the repo after the rebase.